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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the requirements and architecture for the Self Organizing Network (SON) functions 
within the OAM system. SON includes: 

Provision of infrastructure for SON, in the OAM system 

• Enabling SON operations 

• Provide SON capabilities (each of which can either be distributed or centralised) within the OAM 
infrastructure, including their management 

• Access to SON relevant eNodeB attributes 

• Identification of SON relevant eNodeB and UE Measurements 

• Access to and transfer of SON relevant eNodeB and UE measurements 

• Transfer of SON relevant eNodeB alarms 

Define necessary Interface IRPs 

- the automation of neighbour relation lists in E-UTRAN and between different 3GPP Radio Access 
Technologies, 

- self establishment of a new eNodeB in the network, 

- self-configuration and self-healing of eNodeBs, 

- automated coverage and capacity optimisation, 

- optimisation of parameters due to troubleshooting, 

- continuous optimisation due to dynamic changes in the network, 

- automated handover optimisation, 

- optimisation of QoS related radio parameters. 

The SON concept and architecture are described in clause 4. 
The high-level requirements for SON are defined in clause 5. 
Use cases for SON are described in clause 5. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 32.501: "Telecommunication management; Self -Configuration of Network Elements; 

Concepts and Integration Reference Point (IRP) Requirements". 

[3] 3GPP TS 32.5 11: "Telecommunication management; Automatic Neighbour Relation (ANR) 

management; Concepts and requirements". 

[4] 3GPP TS 32.521: "Telecommunication management; Self-Organizing Networks (SON); Self- 

optimization and self-healing; Concepts and requirements". 
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[5] 3GPP TS 32.541: "Telecommunications Management; Self-Healing OAM; Concepts and 

Requirements". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

Centralised SON: SON solution where SON algorithms are executed in the OAM system. Centralised SON has two 
variants: 

NM-Centralised SON: SON solution where SON algorithms are executed at the Network Management level. 

EM-Centralised SON: SON solution where SON algorithms are executed at the Element Management level. 

Distributed SON: SON solution where SON algorithms are executed at the Network Element level. 

Hybrid SON: SON solution where SON algorithms are executed at two or more of the following levels: NE or EM or 
NM. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 



Concepts and background 



4.1 SON concepts 



As a consequence of flattening the access network architecture in E-UTRAN (due to removal of the RNC) it is likely 
that a network operator will require more Release 8 eNodeBs than Release 7 NodeBs in order to cover an equivalent 
geographical area. Network operators have also articulated their requirement to have more flexibility over the choice of 
eNodeB vendor, irrespective of the MME or NMS vendor. 

In order to reduce the operating expenditure (OPEX) associated with the management of this larger number of nodes 
from more than one vendor the concept of the Self-Organizing Network (SON) is introduced. Automation of some 
network planning, configuration and optimisation processes via the use of SON functions can help the network operator 
to reduce OPEX by reducing manual involvement in such tasks. In 3GPP Release 8 many of the signalling interfaces 
between network elements are standardised (open) interfaces. Significant examples in the context of SON are the X2 
interface between eNodeBs and the SI interface between eNodeB and the EPC (e.g. MME, SGW). 

There are four different architectures that are possible for implementing various SON use cases as defined in Section 3. 
The architecture is selected depending on the needs of the SON use cases. 

SON algorithms themselves will not be standardised in 3GPP. 
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5 Business Level Requirements 

5.1 Requirements 
5.1.1 General 

REQ-SON-CON-Ol SON solutions shall provide an easy transition from operator controlled (open loop) to 
autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON. 

REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network 
operators. The impact of individual shared network topographies on proposed SON solutions shall be decided on a case- 
by-case basis. 

REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by 
the SON function shall take effect only after a response by the Operator. 

REQ-SON-CON-06 For closed loop SON function, the implementation of any update proposed by the SON function 
shall take effect without the need for response by the Operator. 

REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred 
between these two modes. The ability to suspend/ resume/ enable/ disable the SON function shall be determined on a 

case by case basis. 

REQ-SON-CON-8 An IRPManager shall be able to monitor the specific results of each particular SON function 

5.2 Actor roles 

IRP Agent. The entity performing the agent role. 

IRP Manager. The entity performing the manager role. 

Network Operations Staff During open loop operation, personnel who manually review the results of the SON 
function at intermediate steps in the particular SON process. The network operations staff decide upon and manually 
initiate the appropriate next step in the SON process. 

5.3 Telecommunications resources 

The managed network equipment. The particular equipment and the need for any SON function(s) within it will be 
specific to each individual use case. 

The OAM system. The location of any SON function(s) within the OAM system will also be specific to each individual 

use case. 

SON Function. The SON algorithm and associated processes that automatically determines the optimum 
configuration, connectivity, or installation parameters for a network element. 

5.4 High-level use cases 

A high-level use case diagram may be presented. In order to understand the use case by subject 

matter experts, they should be augmented with a textual description for each use case. 

The description should serve two purposes: to capture the domain experts' knowledge and to 

validate the models in analysis and design phases with respect to the requirements. 

An example of a high- level use case diagram is given in Appendix I ofM.3020. 
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5.4.1 e-NodeB Sharing Use Case 



e-NodeB 

Sliaring Use 

Case Use case 

stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


A new eNodeB shared by more than one Network Operator is successfully taken 
into service. The IVIME or IVIME Pool to which it is attached is aware that this 
eNodeB serves more than one operator. 




Actors and 
Roles 


Network Operator A - provides IVICC/MNC information and provisions the 

eNodeB. 

Network Operator B - provides MCC/MNC information and gives provisioning 

information to Network Operator A. 




Telecom 
resources 


Planning tool of Network Operator A. 
Shared eNodeB. 




Assumptions 


A commercial relationship exists between the Network Operators. 




Pre-conditions 


Combined provisioning information from both Network Operators is available to 
be downloaded to the new eNodeB. 




Begins when 


The Network Operators agree to share an eNodeB. 




Step 1 (M) 


The operators exchange provisioning data. 




Step 2 (M) 


Network Operator A loads both sets of provisioning data into his Planning tool. 




Step 3 (M) 


The self-establishment process for installation of a new eNodeB retrieves the 
combined data from the Planning Tool. 




Ends when (*) 


The new eNodeB is in service and its associated MME or MME Pool is aware 
that it is a shared eNodeB. 




Exceptions 


None. 




Post-conditions 


Successful if: 

Provisioning data in the eNodeB matches that in the Planning Tool. 

MME or MME Pool is provided with correct information and can distinguish 

between the traffic from each Network Operator that shares the eNodeB. 

Unsuccessful if: 

Mismatch between provisioning data in Planning Tool and eNodeB. 

MME or MME Pool unable to identify either or both of the Network Operators as 

those which share the eNodeB. 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-02 



5.4.2 Transition from Open Loop to Closed Loop Use Case 



Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


The transition from the state where Network Operations personnel intervene and 
act as a manual control and authorisation point for outputs from a SON function, 
to a state where the outputs are used automatically and the personnel merely 
monitor without intervention. 




Actors and 
Roles 


Network Operations personnel - manually installing or updating information 

output from a SON function in the target node(s) via use of the planning tool or 

via the NM/DM at intermediate steps during the open loop phase of the SON 

implementation. 

SON Functions - automatically generating SON outputs for review by the 

Network Operations personnel during open loop operation or for automatic use 

during closed loop operation. 




Telecom 
resources 


Network Management System 
SON function. 




Assumptions 






Pre-conditions 


Initial SON information is defined manually by the network operator and is 
resident on the relevant target node{s). 

The Network Operations personnel defined manual intervention/pause point and 
forces the SON function to take effect only after a response/confirmation by the 
Operator. 

The SON is running in Open Loop. 


REO-SON- 
CON-05[1] 
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Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Begins when 


The Network Operator decides to transit from Open Loop to Closed Loop 
NOTE: The transition may only occur once the operator has gained trust in the 
reliability of the SON. 




Step 1 (0) 


The Network Operations personnel remove the manual intervention/pause point 

either all at once or gradually. 

The Network Operations personnel allow the SON function to run in Closed 

Loop 




Step 2 (M) 


The Network Operations personnel periodically monitor the automatically 
updated SON information and verify that network performance continues to meet 
or exceed planned targets. 




Ends when (*) 


The SON function operates in a closed-loop mode; the SON function takes 
effect without the need for response by the Operator 


REO-SON- 
CON-06[1] 


Exceptions 


The Network Operator disregards the SON function and reverts to manual 
Operation of the Network without any intervention by the SON function, if the 
latter generates SON information that results in unexpected network 
performance. 




Post-conditions 


The SON function is in use and is automatically producing appropriate SON 
information for the target node(s). 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-01 [1] 
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6 Specification level requirements 

6.1 Requirements 

6.1.1 General 

It is likely that only a subset of SON functions can be standardised within the timeframe of the first release of the EPS. 
For that reason a step-by-step roll out of SON functions should be provided. 

6.1 .2 SON in a Multi-Vendor network 

REQ-SON-CON-003 Self-establishment and self-optimisation shall be supported in a multiple vendor environment. 
Standardised procedures and OAM interfaces are needed to avoid cost-intensive mediation between different vendor 
nodes and side effects due to different detailed solutions (e.g. different optimisation algorithm leads to ping-pong 
effects and swinging phenomena). 

REQ-SON-CON-004 The standardised information made available to SON algorithms shall be consistent, 
independent of the vendor. 

6.1 .3 Self-Establishment of a new eNodeB 

Requirements for Self-Establishment of a new eNodeB can be found in TS32.501 [2]. 

6.1 .4 Automatic Neighbour Relation Management 

Requirements for Automatic Neighbour Relation Management can be found in TS32.511 [3]. 

6.1 .5 Self-Optimisation, Self-Healing, Coverage and Capacity 
Optimisation, and Handover Optimisation 

Requirements for Self-Optimisation, Coverage and Capacity Optimisation, and Handover Optimisation can be found in 

TS32.521 [4]. 

Requirements for Self-Healing can be found in TS 32.541 [5]. 

6.1 .6 Continuous Optimisation due to Dynamic Changes in the Network 

REQ-SON-CNO-CON-Ol: An IRPManager shall be able to configure a Hst of valid Physical Cell Identifiers (PCI) in 
the eNB in order to allow the eNB to choose an appropriate PCI for a cell from within this list to support distributed 
PCI assignment. The list of PCIs shall be cell-specific. 

REQ-SON-CNO-CON-02: An IRPManager shall be able to configure a valid PCI in the eNB to support centraUzed 
PCI assignment. The PCI shall be cell-specific. 

REQ-SON-CNO-CON-03: IRP Agent shall support either the distributed or the centralized PCI assignment or both. 

REQ-SON-CNO-FUN-01: IRP Agent shall inform IRPManager about the PCI that is selected for each cell. 

REQ-SON-CNO-FUN-02: IRP Agent shall inform IRPManager about the reason for changing the PCI for a cell. 

REQ-SON-CNO-FUN-03: IRP Agent shall inform IRPManager if a valid PCI cannot be found in the list of PCIs 
configured by IRPManager. 
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6.2 Actor roles 

Actors for Self-Establishment of new eNodeBs can be found in TS32.501 [2]. 
Actors for Automatic Neighbour Relation Management can be found in TS32.51 1 [3]. 

Actors for Self-Optimisation, Coverage and Capacity Optimisation, and Handover Optimisation can be found in 

TS32.521 [4]. 

Actors for Self-Healing can be found in TS 32.541 [5]. 

6.3 Telecommunications resources 

Telecommunications resources for Self-Establishment of new eNodeBs can be found in TS32.501 [2].. 

Telecommunications resources for Automatic Neighbour Relation Management can be found in TS32.511 [3]. 

Telecommunications resources for Self-Optimisation, Coverage and Capacity Optimisation, and Handover Optimisation 
can be found in TS32.521 [4]. 

Telecommunications resources for Self-Healing can be found in TS 32.541 [5]. 
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6.4 



Use cases 



6.4.1 SON in a Multi-Vendor networl< 



6.4.1.1 



Use Case Replacement of eNodeB of Vendor A with one of Vendor B. 



Use case stage 


Evolution/Specification 


«Uses» 
Related use 


Goal 


Seamless replacement of eNodeB from one vendor with that from another. 
Standardised procedures and OAIVI interfaces are needed to avoid cost- 
intensive mediation between different vendor nodes and side effects due to 
different detailed solutions. No adaptation of the Input data to the SON functions 
is necessary due to the replacement of the eNodeB of Vendor A with eNodeB of 
Vendor B. 




Actors and 
Roles 


The Network Operations personnel periodically monitor the automatically 
updated SON information, eNodeB performance, and Network Evolution Plan 
and verify that a particular eNodeB is to be replaced. 
SON Functions - automatically generating SON outputs for automatic use 
during closed loop operation. 




Telecom 
resources 


Network IVIanagement System 

SON function. 

eNodeB 




Assumptions 


Initial SON information is defined manually by the network operator and is 
resident on the eNodeB from Vendor B. 




Pre-conditions 


The SON function is activated on the eNodeB of a Vendor A 
The SON function operates in a closed-loop mode. 




Begins when 


The eNodeB of vendor A is identified for replacement by the Network Operator. 




step 1 (M) 


The eNodeB of vendor B is physically installed in the Network Operator"s 
network. 




Step 2 (M) 


The eNodeB of vendor B is Self-established. The procedure is described in [2]. 
The eNodeB of vendor B is Self-configured. The procedure is described in [2] 


REO-SON- 
CON-03[1] 


Step 3 (M) 


Further SON functions are activated on the eNodeB. 




Ends when (*) 


The eNodeB of Vendor B is connected to the operator"s network and traffic is 
cutover to it from the eNodeB of Vendor A. The SON functions are operating, 
reliably producing appropriate information that results in expected network 
performance. 


REO-SON- 
CON-04[1] 


Exceptions 






Post-conditions 


The eNodeB of Vendor B is operating. The SON function is in use and is 
automatically producing appropriate SON information. 




Traceability (*) 


Requirements or use case exposed by the use case. 


REQ-SON- 
CON-04[1] 



6.4.2 Self-Establishment of a new eNodeB 

Specific use cases for Self Establishment of a new eNodeB can be found in TS32.501 [2]. 

6.4.3 Automatic Neighbour Relation Management 

Specific use cases for Automatic Neighbour Relation Management can be found in TS32.511 [3]. 

6.4.4 Self-Optimisation, Self-Healing, Coverage and Capacity 
Optimisation, and Handover Optimisation 

Specific use cases for Self-Optimisation, Coverage and Capacity Optimisation, and Handover Optimisation can be 
found in TS32.521 [4]. 

Specific use cases for Self- Healing can be found in TS 32.541 [5]. 
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6.4.5 Continuous Optimisation due to Dynamic Cinanges in tine Networl< 
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